Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@examples/ts-react-chat/src/lib/server-fns.ts`:
- Around line 380-394: Replace the no-op inputValidator on chatFn with a real
runtime schema that validates the overall payload shape (e.g., an object with
messages: Array<UIMessage> and optional data), validate each message fields used
by chat (role, content, id, etc.), and remove the unsafe cast "data.messages as
any" so the handler passes the typed/validated messages into chat; update the
inputValidator call to use that schema (or a Zod schema) and ensure
chatFn.handler expects the validated type before calling
chat/openaiText/toServerSentEventsResponse.

In `@examples/ts-react-chat/src/routes/server-fn-chat.tsx`:
- Around line 31-33: The fetcher example passed to useChat uses the wrong call
shape for chatFn; update the fetcher so it forwards the messages correctly by
calling chatFn with data containing messages and the signal (i.e., call chatFn
with an object whose data property wraps messages and includes signal) — locate
the useChat fetcher and replace the current chatFn({ data, signal }) invocation
with the correct shape chatFn({ data: { messages }, signal }) so copy/pasted
examples work as intended.
- Line 18: The handler signature uses React.FormEvent but the React namespace
isn't available under strict TS settings; update imports to include the type and
switch the parameter type: import type { FormEvent } from 'react' and change the
handleSubmit signature from (e: React.FormEvent) to (e: FormEvent) in the
handleSubmit function so the type resolves under moduleResolution: "bundler" and
allowUmdGlobalAccess: false.

In `@packages/typescript/ai-client/src/connection-adapters.ts`:
- Around line 139-150: The code is JSON.parse'ing untrusted stream data and
casting to StreamChunk without validation; update the parsing to validate
against a Zod schema (define a StreamChunkSchema using zod matching StreamChunk
fields) and use StreamChunkSchema.parse or safeParse on the parsed object before
assigning values or yielding; replace direct casts in the block that sets
lastThreadId, lastRunId, lastModel and yields chunk (and the similar occurrences
around the other mentioned locations) with the validated result, handling
validation failures (log/skip/break as appropriate) instead of trusting the
cast.
- Around line 78-83: The trailing-buffer check is misclassifying an intentional
abort as a StreamTruncatedError; update the validation so it only throws
StreamTruncatedError when the stream ended unexpectedly, not when the operation
was aborted. Specifically, in the block that inspects buffer (the code that
currently does if (buffer.trim()) { throw new StreamTruncatedError() }), add a
guard that detects an abort (e.g., check controller.signal?.aborted or a
local/instance flag set by stop()) and skip throwing if aborted—only throw
StreamTruncatedError when buffer.trim() is true AND the abort signal/stop flag
is false. Ensure you reference and use the existing stop() abort mechanism and
the StreamTruncatedError symbol so behavior remains unchanged for genuine
truncation.

In `@packages/typescript/ai-client/tests/chat-client.test.ts`:
- Around line 91-95: Add a regression test that exercises the "both provided"
branch of the ChatClient constructor: construct a new ChatClient passing both a
`connection` and a `fetcher` (e.g., stub/mocked objects) and assert it throws
the same constructor error (the message about requiring either `connection` or
`fetcher`). Target the ChatClient constructor in the existing test file and
mirror the existing pattern used in the empty-transport test so both branches
(none provided and both provided) are covered.

In `@testing/e2e/tests/chat.spec.ts`:
- Around line 26-40: The test 'fetcher mode — streams an SSE Response through
useChat({ fetcher })' currently mirrors the SSE flow and needs a
fetcher-specific assertion; update the test (the async test block using
featureUrl, sendMessage, waitForResponse, getLastAssistantMessage) to
additionally assert a fetcher-only signal—for example, check the UI mode
indicator element text/value that shows "fetcher" is selected after page.goto,
or intercept and inspect the outgoing request body to confirm it used the
fetcher payload shape (e.g., contains a fetcher flag or specific header) before
sending the message; use existing helpers on the page to query the mode element
or route/intercept the request and add an expect that fails if the fetcher
marker is absent.

---

Outside diff comments:
In `@testing/e2e/src/routes/`$provider/$feature.tsx:
- Around line 17-26: validateSearch currently casts any string from search.mode
to Mode using (search.mode as Mode), allowing invalid modes; instead implement a
whitelist: define the allowed Mode values (the Mode union/enum) and check that
typeof search.mode === 'string' and allowedModes.includes(search.mode as Mode)
before returning it, otherwise return undefined. Update the validateSearch
function to perform this include-check (referencing validateSearch, Mode, and
search.mode) so only known/allowed transport modes are propagated.

---

Nitpick comments:
In `@packages/typescript/ai-client/src/chat-client.ts`:
- Around line 33-51: The resolveTransport function currently does manual runtime
checks for connection vs fetcher; replace that logic with a Zod schema that
enforces an exclusive-or (XOR) between ConnectionAdapter and ChatFetcher and
parses the input, then use the parsed result to return either the
ConnectionAdapter or the result of fetcherToConnectionAdapter(fetcher).
Specifically, create a Zod object schema (using z.object and z.union or
z.discriminatedUnion / refine to enforce XOR) that accepts { connection?:
ConnectionAdapter } or { fetcher?: ChatFetcher }, validate the incoming
transport with that schema inside resolveTransport, and throw the same
descriptive errors if validation fails; keep using the same symbols
resolveTransport, ConnectionAdapter, ChatFetcher, and fetcherToConnectionAdapter
so callers and behavior remain unchanged.